Many organisations utilise private networks, whose communications with terminals outside the private network pass through security gateways that protect the private network using techniques including firewalls.
Protection of private corporate information is of utmost importance when designing an information infrastructure. However, the separate private networking solutions are expensive and cannot be updated quickly to adapt to changes. In not by itself ensure privacy. Virtual private networking is the collection of technologies applied to a public network—in particular the Internet—to provide solutions for private networking needs. Virtual private networks use obfuscation through secure tunnels, rather than physical separation, to keep communications private.
Virtual private networks. (‘VPN’) accordingly enable private networks to be extended to enable securitised communication with roaming terminals, that is to say terminals situated outside the private network, the communication passing for example through the internet and possibly over mobile telephone networks. The Internet uses Internet Protocol (‘IP’) and the communications of mobile terminals often use Mobile internet Protocol (‘MIP’).
It is expected that the roaming usage of virtual private networks will become bigger and more frequent. Such frequently roaming users will need to be given the same level of security as fixed or occasional roaming terminals, through the corporate VPN/firewall architecture.
Different communication and security protocols are used for the different networks. An example of internet security protocol is the IPsec specification [S Kerit, R. Atkinson, “Security Architecture for the Internet Protocol”, Internet Engineering Task Force (IETF), RFC 2401, November 1998]. Examples of mobile telephone communication protocols are the Mobile IPv4 specification [C. Perkins “IP Mobility Support”, RFC 2002, October 1996] and the mobile IPv6 specification. When the VPN protocol is IPsec Encapsulating Security Payload and the mobility protocol is Mobile IP, both of them being implemented in the same IP layer, there is a need to specify how these two protocols must interact with each other when being simultaneously required.
Beyond basic application order (either apply Mobile IP first, or apply IPsec first), the overall solution must aim at meeting three major requirements:                Security. The fact that VPN Infrastructure can support Mobile-IP users must not create new security flaws to any corporate entity (corporate network & mobile or occasionally roaming users). Mobile IP enabled devices must provide mobile users with the same level of security as if they were physically located within the corporate network. On the other hand, Mobile IP entitles must be adequately protected by corporate security infrastructure (Firewalls) and Mobile IP specific security mechanism must not interfere with global security mechanism.        Compatibility. A solution that enables optimised Interaction between Mobile IP and IPsec must avoid heavily modifying protocol specifications. Future evolutions of Mobile IP & IPsec protocols must not be made excessively difficult due to the use of an optimised combined solution. Optimally, such evolutions should be transparent to the use of the combined solution.        Performance. The invention must address specific needs of mobile users in terms of handover quality, the handover must be made as quick as possible.        
One example of a communication protocol for a virtual private network is the ESP (Encapsulating Security Payload) protocol (S, Kent, R. Atkinson, “IP Encapsulating Security Payload”, Internet Engineering Task Force (IETF), RFC 2406, November 1998), used in tunnel mode. The most significant points are the following:                The whole incoming IP packet is tunnelled into a new one inner (original) source and destination addresses are not changed.        The whole incoming IP packet is encrypted and optionally (recommended) authenticated.        
ESP tunnel mode is by definition a unidirectional peer-to-peer protocol. The sender (the one that encrypts and tunnels) and the receiver (the one that detunnels and decrypts) must share a cryptographic secret (e.g. key and algorithm used for encryption/decryption). The set of security parameters (protocol), key, algorithm, sender address, receiver address, lifetime, . . . ) constitutes a so-called IPsec Security Association (‘SA’). IPsec requires two SAs (an SA bundle) to obtain a secured unidirectional communication: one on the sender and one on the receiver (with some common parameters, for example the key).
As a VPN communication is bidirectional (from Mobile Node (‘MN’) to VPN Gateway and from VPN Gateway to MN), two SA bundles are required; the first one describes the tunnel from MN to VPN Gateway, the second one describes the tunnel from VPN Gateway to MN. It must be “noted” that the designation “VPN Gateway” is not specified by the protocol: a VPN Gateway is simply the topologic entity that terminates, at the corporate network side, all VPN secure tunnels to/from roaming mobile nodes.
SA selectors are used for the, processing of IPsec packets. Basically, SA selectors are IP parameters that are used by IPsec layer to check that:                A packet that is about to be sent on a tunnel defined by a certain outbound SA is actually legitimate to be sent with that SA (e.g. source & destination addresses of the packet match with source and destination address of the SA). This test is called the “outbound SA selector check”.        A packet that has been received from a tunnel defined by a certain inbound SA is actually legitimate to have been received with this SA (e.g. source & destination addresses of the packet match with source and destination address of the SA). This test is called the “inbound SA selector check”.        
It must be noted that, as illustrated in the two examples above, only source address & destination address will be considered in this invention as SA selectors for both inbound and outbound SAs.
Two families of proposals address this situation;
IPsec tunnel in the MIP tunnel.
With this family of proposals, the IPsec tunnel is established between the VPN Gateway and the Mobile Node Home Address.
External home agent. The home agent is placed in front of the IPsec gateway and the corporate firewall, i.e. outside the home network. Obviously, there are deep security flaws; the main one is that the home agent is no longer protected by the common protection (corporate firewall) mechanism at the border of the network, indeed, a home agent placed outside the gateway does not benefit from any protection and become an easy target. This kind of security flaw could not be accepted when designing a VPN solution aimed at securing communications.
Another problem stems from the tunneling mechanism that does not cipher the MIP packets (the IPsec tunnel is inside the MIP tunnel). The MIP header is in plain test and any attacker with bad intentions will have knowledge of all header fields, for instance the home address of the mobile node. Thus, this solution does not provide privacy and a malicious node might track all successive locations of a mobile node, identified through its home address.
MIP proxy. This proposal is described in a draft (F, Adrangi, P. Iyer, “Mobile IPv4 Traversal across VPN or NAT & VPN Gateway”, IETF work in progress draft-adrangi-mobileip-natvpn-traversal-01.txt, February 2002). It assumes the creation of a new entity called a Mobile IP Proxy that appears as a surrogate home agent from a mobile node point of view and conversely is viewed as a mobile node by the home agent. This solution is also based on IPsec in MIP tunneling, which is less confidential in terms of privacy than MIP in IPsec as stated above.
The process of simple roaming requires new signaling messages between the MIP proxy, the VPN gateway, and the home agent: the MIP proxy acts as a relay between the mobile node and the home agent (‘HA’); it must be aware of existing protection between the mobile node and the HA to forward valid request uniquely. It also interacts with the VPN gateway and a common packet from a corresponding node to a MN follows a heavy process, it is first MIP-encapsulated by the HA to the MIP proxy. Then the MIP proxy decapsulates it and gives it to the VPN gateway in order to realize encryption. The VPN gateway sends back the ciphered packets to the MIP proxy, which encapsulates it again in a new MIP packet.
The MIP proxy is located outside the protected domain in the Demilitarized Zone (‘DMZ’), that is to say a small network inserted as a “neutral zone” between a company's private network and the outside public network. The security level of machines within the DMZ is far inferior to the corporate network. The firewalls must not interfere with the registration procedure between the proxy and the Home Agent. This architecture implies possible security flaws since the corporate firewall must let any packets between the MIP proxy and the Home Agent go through without further inspections; this can easily lead to compromise the entire corporate network if an attacker can manage to gain access to the MIP proxy.
MIP Tunnel in the IPsec Tunnel
With this family proposals, an IPsec tunnel is established between the VPN Gateway and the Mobile Node Care-of Address.
One proposal that includes the MIP tunnel in the IPsec tunnel has been described by the University of Bern, Switzerland at www.iam.unibe.ch/˜rvs/publications/secmip_gi.pdf. The IPsec tunnel is reset before any new handover, when moving to a new network, it has to be re-established through the whole key distribution process. That handover mode creates unacceptable latencies of many seconds, incompatible with classical MIP requirements.
Another issue with this proposal consists in assuming that IPsec offers a sufficient protection and, as a consequence, in disabling authentication and replay protections during the MIP registration procedure. Disabling protections on the Home Agent is an option that does not really improve speed and requires home agents dedicated to MIP-VPN users, as well as other home agents dedicated to simple MIP users that still use MIP protections.